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Abstract 
This document provides recommendations for improving the security of 
the Network News Transfer Protocol (NNTP) when using Transport Layer 
Security (TLS). It modernizes the NNTP usage of TLS to be consistent 
with TLS best current practices. This document updates RFC 4642. 
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1. Introduction 


April 2017 
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The Network News Transfer Protocol (NNTP) [RFC3977] has been using 
Transport Layer Security (TLS) [RFC5246] along with its precursor, 


Secure Sockets Layer (SSL), since at least the year 2000. 


The use of 


TLS in NNTP was formalized in [RFC4642], providing implementation 
recommendations at the same time. In order to address the evolving 
threat model on the Internet today, this document provides stronger 


recommendations regarding that use. 


In particular, this document updates [RFC4642] by specifying that 
NNTP implementations and deployments MUST follow the best current 
practices documented in [BCP195], which currently consists of RFC 
7525 ("Recommendations for Secure Use of Transport Layer Security 
(TLS) and Datagram Transport Layer Security (DTLS)"). This includes 
stronger recommendations regarding SSL/TLS protocol versions, 
fallback to lower versions, TLS negotiation, TLS-level compression, 


TLS session resumption, cipher suites, public key lengths, 
and other 


secrecy, hostname validation, certificate verification, 
aspects of using TLS with NNTP. 
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1.1. Conventions Used in This Document 


Any term not defined in this document has the same meaning as it does 
in [RFC4642] or the NNTP core specification [RFC3977]. 


When this document uses the term "implicit TLS", it refers to TLS 
negotiation immediately upon connection on a separate port. 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in RFC 
2119 [BCP14]. 


2. Updates/Changes to RFC 4642 
This document updates [RFC4642] in the following aspects: 


o NNTP implementations and deployments SHOULD disable TLS-level 
compression (Section 3.3 of RFC 7525 [BCP195]), thus no longer 
using TLS as a means to provide data compression (contrary to the 
Abstract and Section 2.2.2 of [RFC4642]). 


o NNTP implementations and deployments SHOULD prefer implicit TLS, 
and therefore use strict TLS configuration (Section 3.2 of RFC 
7525 [BCP195]). That is to say, they SHOULD use a port dedicated 
to NNTP over TLS and begin the TLS negotiation immediately upon 
connection (contrary to a dynamic upgrade from unencrypted to TLS- 
protected traffic via the use of the STARTTLS command, as 
Section 1 of [RFC4642] was encouraging). Implicit TLS is the 
preferred way of using TLS with NNTP for the same reasons, 
transposed to NNTP, as those given in Appendix A of [MUA-STS]. 
(Note that [MUA-STS] and [RFC4642] have one author in common.) 


o NNTP implementations and deployments MUST NOT negotiate RC4 cipher 
suites ([RFC7465]); this is contrary to Section 5 of [RFC4642], 
which required them to implement the TLS_RSA_WITH_RC4_128_MD5 
cipher suite so as to ensure that any two NNTP-compliant 
implementations can be configured to interoperate. This document 
removes that requirement, so that NNTP client and server 
implementations follow the recommendations given in Sections 4.2 
and 4.2.1 of RFC 7525 [BCP195] instead. The mandatory-to- 
implement cipher suite or cipher suites depend on the TLS protocol 
version. For instance, when TLS 1.2 is used, the 
TLS_RSA_WITH_AES_128_CBC_SHA cipher suite MUST be implemented 
(Section 9 of [RFC5246]). 
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o All NNTP clients and any NNTP server that is known by multiple 
names MUST support the Server Name Indication (SNI) extension 
defined in Section 3 of [RFC6066], in conformance with Section 3.6 
of RFC 7525 [BCP195]. It was only a "SHOULD" in Section 2.2.2 of 
[RFC4642]. 


o NNTP implementations and deployments MUST follow the rules and 
guidelines defined in [RFC6125] and [RFC5280] for hostname 
validation and certificate verification. Part of Section 5 of 
[RFC4642] is, therefore, rationalized in favor of following those 
two documents. 


Appendix A of this document gives detailed changes with regard to the 
wording of [RFC4642]. 


3. Recommendations 


The best current practices documented in [BCP195] apply here. 
Therefore, NNTP implementations and deployments compliant with this 
document are REQUIRED to comply with [BCP195] as well. 


Instead of repeating those recommendations here, this document mostly 
provides supplementary information regarding secure implementation 
and deployment of NNTP technologies. 


3.1. Compression 


NNTP supports the use of the COMPRESS command, defined in Section 2.2 
of [RFC8054], to compress data between an NNTP client and server. 
Although this NNTP extension might have slightly stronger security 
properties than TLS-level compression [RFC3749] (since NNTP 
compression can be activated after authentication has completed, thus 
reducing the chances that authentication credentials can be leaked 
via, for instance, a Compression Ratio Info-leak Made Easy (CRIME) 
attack, as described in Section 2.6 of [CRIME]), this document 
neither encourages nor discourages the use of the NNTP COMPRESS 
extension. 


3.2. Protocol Versions and Security Preferences 


NNTP implementations of news servers are encouraged to support 
options to configure 1) the minimal TLS protocol version to accept 
and 2) which cipher suites, signature algorithms, or groups (like 
elliptic curves) to use for incoming connections. Additional options 
can naturally also be supported. The goal is to enable 
administrators of news servers to easily and quickly strengthen 
security, if needed (for instance, by rejecting cipher suites 
considered unsafe with regard to local policy). 
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News clients may also support similar options, either configurable by 
the user or enforced by the news reader. 


3.3. Server Name Indication 


The TLS extension for Server Name Indication (SNI) defined in 

Section 3 of [RFC6066] MUST be implemented by all news clients. It 
also MUST be implemented by any news server that is known by multiple 
names. (Otherwise, it is not possible for a server with several 
hostnames to present the correct certificate to the client.) 


3.4. Prevention of SSL Stripping 


In order to help prevent SSL Stripping attacks (Section 2.1 of 
[RFC7457]), NNTP implementations and deployments MUST follow the 
recommendations provided in Section 3.2 of RFC 7525 [BCP195]. 
Notably, in case implicit TLS is not used, news clients SHOULD 
attempt to negotiate TLS even if the server does not advertise the 
STARTTLS capability label in response to the CAPABILITIES command 
(Section 2.1 of [RFC4642]). 


3.5. Authenticated Connections 
[RFC4642] already provides recommendations and requirements for 
certificate validation in the context of checking the client or the 
server’s identity. Those requirements are strengthened by 
Appendix A.5 of this document. 
Wherever possible, it is best to prefer certificate-based 
authentication (along with Simple Authentication and Security Layer 
(SASL) [RFC4422]), and ensure that: 


o Clients authenticate servers. 


o Servers authenticate clients. 


o Servers authenticate other peer servers. 


This document does not mandate certificate-based authentication, 
although such authentication is strongly preferred. As mentioned in 
Section 2.2.2 of [RFC4642], the AUTHINFO SASL command (Section 2.4 of 
[RFC4643]) with the EXTERNAL mechanism (Appendix A of [RFC4422]) MAY 
be used to authenticate a client once its TLS credentials have been 
successfully exchanged. 


Given the pervasiveness of eavesdropping [RFC7258], even an encrypted 


but unauthenticated connection might be better than an unencrypted 
connection (this is similar to the "better-than-nothing security" 
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approach for IPsec [RFC5386], and in accordance with opportunistic 
security principles [RFC7435]). Encrypted but unauthenticated 

connections include connections negotiated using anonymous Diffie- 
Hellman mechanisms or using self-signed certificates, among others. 


Note: when an NNTP server receives a Netnews article, it MAY adda 
<diag-match> (Section 3.1.5 of [RFC5536]), which appears as "!!" in 
the Path header field of that article, to indicate that it verified 
the identity of the client or peer server. This document encourages 
the construction of such Path header fields, as described in 

Section 3.2.1 of [RFC5537]. 


3.6. Human Factors 


NNTP clients SHOULD provide ways for end users (and NNTP servers 
SHOULD provide ways for administrators) to complete at least the 
following tasks: 


o Determine if a given incoming or outgoing connection is encrypted 
using a security layer (either using TLS or an SASL mechanism that 
negotiates a security layer). 


o Be warned if the version of TLS used for encryption of a given 
stream is not secure enough. 


o If authenticated encryption is used, determine how the connection 
was authenticated or verified. 


o Be warned if the certificate offered by an NNTP server cannot be 
verified. 


o Be warned if the cipher suite used to encrypt a connection is not 
secure enough. 


o Be warned if the certificate changes for a given server. 


o When a security layer is not already in place, be warned if a 
given server stops advertising the STARTTLS capability label in 
response to the CAPABILITIES command (Section 2.1 of [RFC4642]), 
whereas it advertised the STARTTLS capability label during any 
previous connection within a (possibly configurable) time frame. 
(Otherwise, a human might not see the warning the first time, and 
the warning would disappear immediately after that.) 


o Be warned if a failure response to the STARTTLS command is 


received from the server, whereas the STARTTLS capability label 
was advertised. 
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Note that the last two tasks cannot occur when implicit TLS is used, 
and that the penultimate task helps prevent an attack known as "SSL 
Stripping" (Section 2.1 of [RFC7457]). 


4. Security Considerations 


Beyond the security considerations already described in [RFC4642], 
[RFC6125], and [BCP195], the following caveat is worth mentioning 
when not using implicit TLS: NNTP servers need to ensure that they 
are not vulnerable to the STARTTLS command injection vulnerability 
(Section 2.2 of [RFC7457]). Though this command MUST NOT be 
pipelined, an attacker could pipeline it. Therefore, NNTP servers 
MUST discard any NNTP command received between the use of STARTTLS 
and the end of TLS negotiation. 


5. IANA Considerations 


This document does not change the formal definition of the STARTTLS 
extension (Section 6 of [RFC4642]). Nonetheless, as implementations 
of the STARTTLS extension should follow this document, IANA has added 
reference to this document to the existing STARTTLS label in the 
"NNTP Capability Labels" registry contained in the "Network News 
Transfer Protocol (NNTP) Parameters" registry: 


4+---------- 4+-------------------------- 4+-------------------- + 
| Label | Meaning | Reference 

4+---------- 4+-------------------------- 4+-------------------- + 
| STARTTLS | Transport layer security | [RFC4642] [RFC8143] | 
+---------- +-------------------------- +-------------------- + 
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Appendix A. Detailed Changes to RFC 4642 


This section lists the detailed changes that this document applies to 
[RFC4642]. 


A.1. 


Related to TLS-Level Compression 


The second sentence in the Abstract in [RFC4642] is replaced with the 
following text: 


The primary goal is to provide encryption for single-link 
confidentiality purposes, but data integrity, and (optional) 
certificate-based peer entity authentication are also possible. 


The second sentence of the first paragraph in Section 2.2.2 of 
[RFC4642] is replaced with the following text: 


The STARTTLS command is usually used to initiate session security, 
although it can also be used for client and/or server certificate 
authentication. 


Related to Implicit TLS 


The third and fourth paragraphs in Section 1 of [RFC4642] are 
replaced with the following text: 


Elie 


TCP port 563 is dedicated to NNTP over TLS, and registered in the 
IANA Service Name and Transport Protocol Port Number Registry for 
that usage. NNTP implementations using TCP port 563 begin the TLS 
negotiation immediately upon connection and then continue with the 
initial steps of an NNTP session. This immediate TLS negotiation 
on a separate port (referred to in this document as "implicit 
TLS") is the preferred way of using TLS with NNTP. 


If a host wishes to offer separate servers for transit and reading 
clients (Section 3.4.1 of [NNTP]), TCP port 563 SHOULD be used for 
implicit TLS with the reading server, and an unused port of its 
choice different than TCP port 433 SHOULD be used for implicit TLS 
with the transit server. The ports used for implicit TLS should 
be clearly communicated to the clients, and specifically that no 
plaintext communication occurs before the TLS session is 
negotiated. 


As some existing implementations negotiate TLS via a dynamic 
upgrade from unencrypted to TLS-protected traffic during an NNTP 
session on well-known TCP ports 119 or 433, this specification 
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to 


formalizes the STARTTLS command in use for that purpose. However, 
as already mentioned above, implementations SHOULD use implicit 
TLS on a separate port. 


Note: a common alternative to protect NNTP exchanges with transit 
servers that do not implement TLS is the use of IPsec with 
encryption [RFC4301]. 


additional informative reference to [RFC4301] is, therefore, added 
Section 7.2 of [RFC4642]. 


Related to RC4 Cipher Suites 


The third paragraph in Section 5 of [RFC4642] is removed. 
Consequently, NNTP no longer requires the implementation of any 
cipher suites, other than those prescribed by TLS (Section 9 of 
[RFC5246]), and Sections 4.2 and 4.2.1 of RFC 7525 [BCP195]. 


A.4. 


Related to Server Name Indication 


The last two sentences of the seventh paragraph in Section 2.2.2 of 
[RFC4642] are removed. Section 3.6 of RFC 7525 [BCP195] applies. 


A.5. 


Related to Certificate Verification 


The text between "During the TLS negotiation" and "identity 
bindings)." in Section 5 of [RFC4642] is replaced with the following 
text: 
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During TLS negotiation, the client MUST verify the server’s 
identity in order to prevent man-in-the-middle attacks. The 
client MUST follow the rules and guidelines defined in [RFC6125], 
where the reference identifier MUST be the server hostname that 
the client used to open the connection, and that is also specified 
in the TLS "server_name" extension [RFC6066]. The following NNTP- 
specific consideration applies: DNS domain names in server 
certificates MAY contain the wildcard character "*" as the 
complete leftmost label within the identifier. 


If the match fails, the client MUST follow the recommendations in 
Section 6.6 of [RFC6125] regarding certificate pinning and 
fallback. 


Beyond server identity checking, clients also MUST apply the 
procedures specified in [RFC5280] for general certificate 
validation (e.g., certificate integrity, signing, and path 
validation). 
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Additional normative references to [RFC5280] (replacing [PKI-CERT], 
which it obsoletes), [RFC6066], and [RFC6125] are, therefore, added 
to Section 7.1 of [RFC4642]. 


A.6. Related to Other Obsolete Wording 


The first two sentences of the seventh paragraph in Section 2.2.2 of 

[RFC4642] are removed. There is no special requirement for NNTP with 
regard to TLS Client Hello messages. Section 7.4.1.2 and Appendix E 

of [RFC5246] apply. 
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